レビューで工夫したみた
2024.07.30こんにちは、高崎＠アノテーションです。
はじめに
我々は LINE ミニアプリの運用保守業務に携わっております。
運用保守が通常業務ですと、例えばライブラリアップデートやちょっとした画面リソースの更新といった業務が主ですが、最近になって中規模のエンハンス開発（追加開発）にも携わるようになるうちに、表題の通り生成物に関するレビューを少し工夫して進めた話をしたいと思います。
工夫１
１つ目は「レビュー対象物」に行ったヒトサジの工夫です。
追加開発を行う場合はソースはもちろんのこと、設計書やデータ定義書といったそれまでの生成物がありますが、この生成にあたり、お客様との要件のすり合わせ、仕様検討、実装に至るまでの経緯があるはずですが、そういった経緯がわからず改めて確認することがありました。
確認したうえで、新たな追加要件をお客様と整理して検討、実装に至ってレビューと言う流れになりますが、改めて振り返ると、作成途中の経緯を残さないと、後段で改めて追加開発が始まった場合にまた同じように最初から確認することが起こり得ると考えました。
そこで、レビュー対象物の作成に至った経緯といった「設計書やソースの行間」と言った下記の情報を残すようにしました。
- お客様と要件を整理した記録
- 設計方針を検討した内容（明確なものは省略）
- 改修対象のソースを調査した内容（検索した文言や対応要否）
- ソースの実装方針
これはいわゆる ADR（Architecture Decision Report） と言われるものだと思いますが、経緯をあわせてレビュー対象物にしました。
レビューを進める
レビューにてこの ADR の妥当性を評価します。
何か課題があれば、これらを TODO として残し何時までに対応する必要があるのか、といったところを皆で検討し記録します。
そうすることで、ソースや設計書だけではない、作成の経緯を品質記録として残すことができ、新たに新規のメンバーが入った時でも少しスムーズに立ち上がるものとなりえます。
工夫２
もう一つの工夫は「レビュー実施」に行ったヒトサジの工夫です。
レビューと聞くと、
- 設計や実装をアラ探しされる
- 実装方法を批判される
といったネガティブな印象 [1] もありますが、レビュー（review）を英訳では、
- 再検査
- 評価
- 批判
といったネガティブな印象を受けます。
一方で、review には、
- 振り返り
と訳することができます。
レビューはすなわち「レビューアの振り返りの場」でもあるわけです。
レビュー＝振り返りで考えてみる
振り返りのフレームワークにKPTがありますが、Problem（レビュー対象物への問題指摘）や Try（指摘された課題に対する施策や修正）はレビューからも出てきますが、Keep は一見して出てこないように思います。
そこで、Keep の要素としてレビュー対象物の良かった点を残すようにしてはいかがでしょうか。
- この検討方法や視点が良かった
- このコメントは非常に見やすかった
- きめ細やかなテストケースだ
- この要件は非常に複雑でお疲れ様でした
…といった、対象物を褒めることで、次に繋がる手法をナレッジで残すことができます。
弊チームではレビューの際は良かった点をできるだけ残すよう、意識付けをしています。
おわりに
昨今ソフトウェアの問題が様々な媒体で報道され、以前と比べてソフトウェアに対する「世間の目」が厳しくなっているように思います。
そこで、レビューを厳しくするというのも一つの手かもしれませんが、むしろ活発に皆が意見を出し合ってチームで合意して決定して行く仕組みを作る方がより強固なソフトウェアが作れると思います。
アノテーション株式会社について
アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。
サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイト をぜひご覧ください。
Google で「ソフトウェア レビュー 課題」で検索すると「揚げ足取りで個人攻撃にならないように」といった一文も見つけられました ↩︎
